Efficient framing procedure for variable length packets

ABSTRACT

A method of processing Ethernet signals for transport in an optical network system is disclosed. The method includes encapsulating Ethernet frames into EFP frames comprising a length header, a converged data link header, and a data area, and mapping the EFP frames into byte synchronous paths. The converged data link header replaces an Ethernet preamble of the Ethernet packet.

BACKGROUND OF THE INVENTION

[0001] The present invention relates generally to digital communicationnetworks, and more specifically, to an efficient framing procedure forvariable length packets.

[0002] Efficient transfer of traffic requires a network designed inconformance with conventional voice network and suitable fortransferring variable length packets. Conventionally, there is SONET/SDHas a digital network for WAN (Wide Area Network). SONET and SDH are aset of related standards for synchronous data transmission over fiberoptic networks. SONET is short for Synchronous Optical Network and SDHis an acronym for Synchronous Digital Hierarchy. SONET is the UnitedStates version of the standard published by the American NationalStandards Institute (ANSI). SDH is the international version of thestandard published by the International Telecommunications Union (ITU).

[0003] Increase in bandwidth demand has been satisfied through acombination of increased line rates (Time Division Multiplexing (TDM))and transmitting multiple wavelengths through a single fiber (Dense WaveDivision Multiplexing (DWDM)). ITU recommendation G.709 (“Interface forthe Optical Transport Network (OTN))” builds on the experience andbenefits gained from SDH and SONET to provide a route to thenext-generation optical network. The ITU-T G.709 frame includes threeparts: overhead area for operation, administration, and maintenancefunctions; payload area for customer data; and forward error correction(FEC). FEC provides additional coded data to enable error checking andcorrection by a receiving device. There are also conventional FECimplementations based on ITU-T G.975 which support only the transmissionof SONET/SDH signal and can not carry OPU.

[0004] ITU-T G.709 links running at an appropriate rate can carry 2.5Gb/s Ethernet (2.5 Gb/s Ethernet is not included in the IEEE 802.3standard but may be used in proprietary systems, for example), 10 Gb/sEthernet, and future rate Ethernet. However, there are difficulties withthe transparent transport of 10 GE (Gigabit Ethernet) interface, whichmay or may not transport CDL information (described below), over a WDMsystem that uses FEC to improve optical system performance. Currentlythere are two different approaches to solve this problem. One is basedon the over clocking of the G.709 frame rate that runs at 10.709 Gb/s ata rate up to 11.09 Gb/s in order to transport the 10.3 Gb/s clientsignal. The second is the use of ITU-T G.7041 mapping over ITU-T G.709.Both of them have drawbacks. For example, ITU-T G.709 overclockingrequires a higher bit rate, which may result in system and hardwareproblems. ITU-T G.7041 GFP mapping does not provide preambletransparency which creates compatibility issues for technologies such asconverged data link (CDL) Ethernet (described in U.S. patent applicationSer. No. 09/668,253, filed Sep. 21, 2000, which is incorporated byreference herein in its entirety). IEEE is in the process ofstandardizing uses of the Ethernet preamble for technologies such as CDLEthernet. Transport of CDL Ethernet over WDM or ultra-long reach linksresults in additional requirements. For example, starting at 10 Gb/s forultra-long reach transmission and for future higher bit rates for evenlonger reach transmission, FEC is required. Furthermore, as opticalswitching without OEO conversion is deployed, some OAM informationpertaining to all the wavelengths needs to be carried on a separatesupervisory wavelength.

[0005] Unlike SONET, Ethernet networks rely on non-synchronous signalingtechniques. Gigabit Ethernet uses the same frame format specified by theoriginal Ethernet Standard, including variable frame length specified inthe Ethernet Standard. Framing procedures have been developed toaccommodate variable-length packets with various protocols in an OTNusing WDM in addition to SONET/SDH. However, existing framing procedures(e.g., HDLC, Generic Framing Procedure Transparent Mode, Generic FramingProcedure Fame Mode) suffer from disadvantages such as variablebandwidth overhead and high overhead that may result in bandwidthlimitation and transparency issues. The high overhead makes it virtuallyimpossible to carry a full 10 Gb/s Ethernet signal in SONET OC-192C orOTN OTU2 byte containers. For example, OTU2 cannot carry 10 Gb/sEthernet using GFP transparent mode. OPU2 payload capacity is notsufficient for direct mapping of 64B/66B code words. GFP Frame MappedMode cannot be used to transport CDL Ethernet, since the Ethernetpreamble is discarded. Furthermore, extensions to the GFP Frame MappedMode maintain its high overhead. These overheads are provided to supportcapabilities that are redundant to CDL Ethernet. For example, GFP FrameMapped Mode defines an idle packet. CDL Ethernet already includes anidle packet. Furthermore, GFP Frame Mapped Mode defines clientmanagement packets which compete with client packets for bandwidth orhave an indeterminate latency. In the case of FEC based on G.975 thatsupport only OC-192/5TM-16 signal, the GFP frame mapping over SONET/SDHpayload will reduce the available bandwidth down to 9.584 Gb/s.

[0006] Further drawbacks to GFP include the rate control (e.g. theopen-loop rate control in 10 Gb/s WAN PHY and compatible MAC) which isrequired to carry 10 Gb/s Ethernet into OC192. GFP also requires use ofthe linear extension header and therefore even larger overhead andlowering of the rate to support packet-by-packet multiplexing. Moreover,transport network elements are needed by GFP to inject frames into theclient frame stream for OAM&P. In the case of FEC based on G.975 thatsupport only OC-192/STM-16 signal, the GFP frame mapping over SONET/SDHpayload will reduce the available bandwidth down to 9.584 Gb/s.

[0007] In the absence of a suitable encapsulation/mapping procedure, andto meet the above objectives, an efficient framing procedure forEthernet is needed.

SUMMARY OF THE INVENTION

[0008] A method of processing Ethernet signals for transport in anoptical network system is disclosed. The method comprises encapsulatingEthernet frames into EFP frames comprising a length header, a convergeddata link header, and a data area, and mapping the EFP frames into bytesynchronous paths. The converged data link header replaces an Ethernetpreamble of the Ethernet packet. The converged data link header may havebeen inserted into the Ethernet frame prior to encapsulation.

[0009] The method may include SONET/SDH mapping, G.975 FEC mapping, orOTU/G.709 mapping, for example.

[0010] In another aspect of the invention, a method for framing bytealigned variable length packets for transport in an optical networksystem comprises replacing a preamble of the packet with a headercomprising an operations, administration, and maintenance field, amessage channel, an application specific field, and a header errordetection field, which attempts to maximize the bandwidth.

[0011] The above is a brief description of some deficiencies in theprior art and advantages of the present invention. Other features,advantages, and embodiments of the invention will be apparent to thoseskilled in the art from the following description, drawings, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012]FIG. 1 illustrates a simplified Ethernet frame format.

[0013]FIG. 2A illustrates an EFP frame format for Ethernet packets.

[0014]FIG. 2B illustrates an EFP frame format for idle frames.

[0015]FIG. 3 illustrates a format of a Converged Data Link (CDL) header.

[0016]FIG. 4 is a diagram illustrating transmitting flow rate adaptationbetween a 10 GE client interface and an FEC payload rate.

[0017]FIG. 5 is a diagram illustrating receiving flow rate adaptationbetween a 10 GE client interface and an FEC payload rate.

[0018]FIG. 6 is a flowchart illustrating a process for the flow rateadaptation shown in FIG. 4.

[0019]FIG. 7 is a system block diagram of a computer system that can beutilized to execute software of an embodiment of the present invention.

[0020] Corresponding reference characters indicate corresponding partsthroughout the several views of the drawings.

DETAILED DESCRIPTION OF THE INVENTION

[0021] The following description is presented to enable one of ordinaryskill in the art to make and use the invention. Descriptions of specificembodiments and applications are provided only as examples and variousmodifications will be readily apparent to those skilled in the art. Thegeneral principles described herein may be applied to other embodimentsand applications without departing from the scope of the invention.Thus, the present invention is not to be limited to the embodimentsshown, but is to be accorded the widest scope consistent with theprinciples and features described herein. For purpose of clarity,details relating to technical material that is known in the technicalfields related to the invention have not been described in detail.

[0022] The present invention operates in the context of a datacommunication network including multiple network elements. The networkmay be a packet based optical network that uses Ethernet data layer atspeeds of 10 Gb/s (or above or below 10 Gb/s), both over high speedpoint-to-point circuits (i.e., dark fiber) and over WDM. However, it isto be understood that the system may be used with media types differentthan those described herein, without departing from the scope of theinvention. A network element may be, for example, a terminalmultiplexer, an add-drop multiplexer (ADM), an optical crossconnect(OXC), a signal regenerator, router, switch, or other optical nodeinterface. The invention described herein may be implemented indedicated hardware, microcode, software, or photonic (optical) logic.

[0023] An efficient framing procedure (EFP) for Ethernet is describedherein. EFP is a method of delineating Ethernet packets (i.e., bytealigned variable length packets) for subsequent mapping into bytesynchronous paths such as the SONET/SDH and OTN (based on, for example,ITU-T G.975). EFP also provides a set of adaptation functions forsubsequent mapping into byte synchronous paths such as the SONET/SDH andOTN.

[0024] As described in detail below, EFP carries all seven Ethernetpreamble bytes and removes the SFD. EFP is able to carry CDL basedEthernet packets with the removed SOF. EFP adds four bytes; two forlength and two for CRC to enable single bit correction and multi-bitdetection within the two length bytes. EFP enables 10 Gb/s Ethernet tobe mapped into constant bit stream (e.g., at 9.953 Gb/s) for maximumpacket sizes less than 1878 bytes. This also applies to direct mappingover G.975 FEC payload. EFP also enables 10 Gb/s Ethernet to be mappedinto OTU2 for maximum packet sizes less than 15177 bytes withoutrequiring any rate control. Thus, EFP enables use of 10 Gb/s Ethernet inlong haul networks where FEC is a requirement. EFP, through itsinclusion of CDL (Converged Data Link) header supports packet-by-packetmultiplexing and OAM&P.

[0025] Referring now to the drawings, and first to FIG. 1, a simplifiedexample of an Ethernet frame 20 is shown. The frame includes a preamble24, start of frame delimiter (SFD) 26, and a data field 28 (whichincludes CRC (Cyclic Redundancy Checks). Standard IEEE 802.3 Ethernetpackets typically include the following fields (not shown) after thepreamble: destination address, source address, length or type field,data field, and frame check sequences.

[0026]FIG. 2A illustrates an example of an EFP encapsulated frame 30.The EFP frame 30 is byte aligned and consists of a Length Header, a CDLHeader 36, and an EFP Data area 40. The Length Header includes a 16-bitlength field 32 (supporting packets of size up to 64 k bytes) and a16-bit length CRC (LCRC) field 34. The length encompasses the entireframe and the minimum value for length is preferably 11. This minimumvalue is used to fill the bandwidth when no Ethernet Packets areavailable or when CDL idle packets are received from a client interface.A value of zero in the length field identifies an EFP idle frame. Lengthvalues from 1 to 10, inclusive, are reserved for future definition. TheLength Header is scrambled by exclusive-OR (also known as “modulo 2addition”) with the hex value B6AB31E0 (which is the maximum transition,minimum sidelobe, Barker-like sequence of length 32).

[0027] The 16-bit LCRC is computed over the 16-bit length field. It isused for single bit error correction and multi-bit error detection. TheLCRC generating polynomial may be, for example:

G(x)=x{circumflex over ( )}16+x{circumflex over ( )}12+x{circumflex over( )}5+1

[0028] where:

[0029] x{circumflex over ( )}16 corresponds to the most significant bit;and

[0030] x{circumflex over ( )}0 corresponds to the least significant bit.

[0031] The 16-bit Length is taken to be a polynomial L(x) of degree 15.L(x) is multiplied by x{circumflex over ( )}16 (modulo-2) and divided byG(x). The remainder is a polynomial C(x) of degree 15 or less and is theLCRC. LCRC is transmitted MSB (coefficient of x{circumflex over ( )}15)first.

[0032] Packet delineation is performed using a 2-byte length and 2-bytelength CRC. Frame delineation may be performed, for example, using theLength and the LCRC in a Hunt procedure. The Hunt procedure is performedin parallel over eight streams. When a pre-synch state is reached (i.e.,a match between length and CRC is found) and is maintained for the nextframe, the synch is declared.

[0033] The CDL Header is described in U.S. patent application Ser. No.09/668,253, filed Sep. 21, 2000, entitled Method and System forProviding Operations, Administration, and Maintenance Capabilities inPacket Over Optics Networks, which is incorporated herein by referencein its entirety. The CDL header provides operations, administration,maintenance and provisioning (OAM&P) (or OAM, or any single feature orcombination thereof), multiplexing, and multiple qualities of service inpacket over optics networks. For example, CDL may support generalmanagement of optical networks, supervision of unused channels,provisioning of optical paths, performance monitoring of optical paths,and failure recovery. CDL also enables multiplexing of multiple logicallower speed circuits across a single optical channel including supportfor a multi-access form of statistical multiplexing appropriate to ringtopologies and support for frame-by-frame multiplexing. It is to beunderstood that CDL may provide all of the above mentioned functions,only one of these functions, or any combination thereof, withoutdeparting from the scope of the invention. CDL Ethernet employs the samePMA and PCS layers as Ethernet for signal rates of 100 Mb/s, 1000 Mb/s,and 10 Gb/s. This addresses transport of Ethernet and CDL Ethernet overshort reach, intermediate reach, and long reach dark fiber links.

[0034] CDL is a wrapper around the link layer packet. The CDL wrappercomprises a self-contained 7 byte CDL header that is prepended tostandard Ethernet packets (e.g., IEEE 802.3) by replacing a preamble ofthe Ethernet packet. When applied to a standard Ethernet frame (IEEE802.3), the CDL wrapper substitutes the SFD byte and the preceding sixpreamble bytes. The Ethernet frame is located after the CDL header,which replaces bytes in the standard Ethernet preamble. It is tounderstand that although the invention is described herein using anEthernet packet, other types of packets having a preamble may also beused. Thus, the term “Ethernet packet” or “Ethernet frame” as usedherein includes packets or frames formatted according to standards otherthan IEEE 802.3.

[0035]FIG. 3 illustrates an example of fields within the CDL header. Thefields preferably included in the CDL header 36 are:

[0036] Byte [1]: Packet type and OAM information 44

[0037] Byte [2]: Message channel 46

[0038] Byte [3-6]: Application specific information 48

[0039] Byte [7]: Header cyclic redundancy check (CRC) 50

[0040] The OAM field 44 carries packet type information, error flags,and an automatic protection switching (APS) subchannel. OAM includes,for example, the following fields:

[0041] PT: Packet Type Field

[0042] AF: APS Framing

[0043] EB: End-to-end Backward Defect Indication (BDI-E)

[0044] EF: End-to-end Forward Defect Indication (FDI-E)

[0045] HB: Hop-by-hop Backward Defect Indication (BDI-H)

[0046] HF: Hop-by-hop Forward Defect Indication (FDI-H)

[0047] Automatic protection switching (APS) provides the capability of atransmission system to detect a failure on a working facility and toswitch to a standby facility to recover the traffic, thus, improvingoverall system availability. The type field identifies whether or notthe data and CRC fields are present.

[0048] The message channel 46 provides a communication mechanism betweennetwork elements. Messages are hop-by-hop and may be forwarded or routedaccording to established routing protocols. The message channel 46allows management communication over the same physical facilities as theuser data but without taking any bandwidth from the user data.

[0049] The application specific (AS) field 48 carries informationbetween end nodes that is forwarded along an optical path. Theapplication specific field 48 may include a subinterface identifier toassist in multiplexing packet streams. The application specific field 48may also be used to support applications other than multiplexing. Forexample, the application specific field 48 may be used to facilitatemulti-protocol label switched routing.

[0050] The header CRC 50 is employed for header error protection andcovers the CDL header. The CRC is preferably computed over the entirevalue of the CDL header, including the AS field 48. The CRC may be basedon CRC-8 [ITU-T G.432.1]. For example, the CRC header may be an 8-bitsequence that is the remainder of the modulo-2 division by the generatorpolynomial x{circumflex over ( )}8+x{circumflex over ( )}2+x+1 of theproduct x{circumflex over ( )}8 multiplied by the content of the CDLheader excluding the header CRC. The 48-bit long relevant portion of theCDL header is taken to represent a polynomial of order 47. Thecoefficients can have the value 0 or 1. The first bit of the headerrepresents the coefficient of the highest order (x{circumflex over( )}47) term. The polynomial operations are performed modulo-2. The CRCheader is preferably recomputed whenever any of the fields in the headerare changed and passed transparently whenever the fields of the headerdo not change.

[0051] It is to be understood that other related or unrelated fields maybe included between any of the above fields or the fields may be in adifferent order without departing from the scope of the invention.

[0052] Referring again to FIG. 2A, the EFP frame includes EFP Data 40.The EFP Data area may be scrambled using a 1+x{circumflex over ( )}43self-synchronous scrambler. If it is not required to provide securityagainst payload information replicating scrambling word (or its inverse)from a frame synchronous scrambler, such as those used in the SDH RSlayer or in an OTN OPUk channel, the Data area may not be scrambled. Thecontent of Data area 40 preferably includes an FCS (Frame CheckSequencer) field for Ethernet packets.

[0053] EFP packet types include EFP Ethernet packet, EFP CDL idle, andEFP idle. The EFP CDL idle is the mapping of a CDL idle packet comingfrom the client interface that has to be propagated to the far endclient. The EFP CDL idle includes the length 32, length CRC 34, and CDLheader 36 fields. EFP CDL is used for fault propagation purposes, asdescribed above. The EFP idle, shown in FIG. 2B, is used to fill thebandwidth when there is nothing to transmit. The EFP idle frame isprovided as a filler frame, since one of the requirements for mappingEFP frames into octet synchronous paths is for the capacity of suchpaths to be not less than the capacity required by the Ethernet stream.The EFP idle frame may also be used to enable frequency tolerancecompensation. EFP Idle Frames have a length of 11 and are identified by0 in the Length field 32.

[0054] Defect Handling is provided by the CDL header. A Client SignalFail condition (e.g., loss of signal) is handled by the EFP sourcegenerating a stream of all EFP Idle frames and setting the FDI-H bit inthe CDL header (see previous description of defect indication bytes inCDL header). The 10 Gb/s EFP sink, on receiving the EFP Idle frame withFDI-H bit set, begins to forward the LF SOS (Local Fault SequenceOrdered Set), as specified, for example, in IEEE 802.3ae 10 Gb/sEthernet Task Force, Section 46.3.2. The EFP sink stops to forward LFSOS if an EFP Idle frame with FDI-H bit clear or an EFP Client Dataframe is received. A 10 Gb/s EFP source, upon receiving RF (RemoteFault) SOS and determining the RF condition, begins to generate a streamof all EFP Idle frames. The BDI-E bit the CDL Header is then set.

[0055] The 10 Gb/s EFP sink, upon receiving EFP Idle frame with BDI-Ebit set or an OTU2-AIS (Alarm Indication Signal) defined by the ITUG.709 standard, begins to forward RF SOSs. The EFP source stopsforwarding EFP Idle frames with BDI-E set when the RF condition clears(as specified in IEEE 802.3ae Section 46.3.2). The EFP sink stopsforwarding RF SOSs if an EFP Idle frame with BDI-E bit clear or an EFPClient Data frame is received or OTU2-AIS clears (as specified in ITU-TG.709). In addition, an LF and RF indication are propagated to the farend using the same CDL FDI/BDI propagation mechanism.

[0056] When Ethernet traffic is sent to a SONET/SDH network, theEthernet frames are first mapped into a frame with an appropriatestructure and then mapped to the SONET (or other appropriate payloadenvelope). The following describes how EFP may be used to transport 10GE interface over a WDM system that uses FEC to improve optical systemperformance. In one embodiment, the system provides rate adaptationbetween a 10 GE client interface (10.3125 Gb/s) and a G.975 FEC payloadrate (9.9532/s).

[0057]FIG. 4 is a high level block diagram illustrating rate adaptationin the transmitting direction. The 10.3125 Gb/s signal is converted toan XGMII (10G Medium Independent Interface) through a standard EthernetPCS (Physical Coding Sub-layer) block 60. The IPGs (InterPacket Gaps) 62are then removed and the EFP mapping procedure (described above) is usedto build a constant bit stream running at 9.9532 that will be sent toFEC payload 68 for encoding. EFP framing is performed and EFP idleframes 64 are inserted as required. The signal may be mapped into an FECframe of a long-haul DWDM transport platform, such as ONS 15808,available from Cisco Systems, Inc. of San Jose, Calif., for example. Tomaximize the available bandwidth, the insertion of overhead bytes ispreferably limited to three (the minimum set required for alignmentpurposes).

[0058]FIG. 5 illustrates receiving flow rate adaptation. The EFP frames30 are preferably detected using a parallel Hunt algorithm to minimizethe time for EFP alignment. The EFP overhead is then removed and the IPGand the SFD are reinserted. After the EFP de-mapping process is completethe Ethernet packets 20 are sent to PCS coding block 60 and IPG 62 areinserted as required. If the client network is based on standardEthernet (IEEE 802.3), the packet preamble bytes are replaced by CDLpreamble. If the client network includes CDL preamble capability, thepreamble bytes are passed through.

[0059]FIG. 6 is a flowchart illustrating the flow rate adaptationdescribed above along with two additional methods. At step 70, PCS blockdecoding is performed. Packet buffer for length calculation is performedat step 72. Next, idle removal and EFP mapping are performed (step 74).At step 78, a 9.953 Gb/s constant bit stream signal is built to bemapped into a G.975 FEC frame (as previously described). As shown atstep 76, the EFP packet may also be mapped into a SONET/SDH payload(OC-192/STM-64 transceiver). Another option is to build an EFP stream of9.995 Gb/s (OPU2 payload rate) so that the EFP stream can be directlymapped into a ITU-T G.709 frame (step 80).

[0060] The available bandwidth for Ethernet packet transport in thethree methods of FIG. 6 (steps 76, 78, and 80) is as follows:

[0061] 9.584 Gb/s for SONET/SDH mapping

[0062] 9.953 Gb/s for G.975 FEC mapping

[0063] 9.995 Gb/s for OTU/G.709 mapping

[0064] The following is an example of a calculation of the maximumpacket size (L) that can be carried using EFP.

(L+IPG _(min))WDMPayload _(—) rate(1−DeltavWDM)=(L+EFP_(OH))10G(1+DeltavClient)ΔV _(max)=10G(1+DeltavClient)−WDMPayload _(—)rate(1−DeltavWDM) $L = \frac{\begin{matrix}{{{WDMPayload\_ rate}\left( {1 - {DeltavWDM}} \right){IPG}_{\min}} -} \\{10{G\left( {1 + {DeltavClient}} \right)}{EFP}_{OH}}\end{matrix}}{\Delta \quad V_{\max}}$

[0065] From the above equation, the maximum packet size (L) that can becarried by the SONET OC192 signal using EFP is calculated asapproximately 19000 bytes for OPU mapping, 1800 for G.975 FEC payload(9.953 Gb/s) and 200 for OC-192/STM16 mapping. Precise values depend onthe clock accuracy.

[0066] The following table provides examples of calculations for maximumpacket size (L) for payload rates (WDMPayload_rate) of 9.54 Gb/s, 9.953Gb/s, and 9.999. Gb/s with an IPG of 12 and 70: SONET/SDH G.975 FEC OTNPayload rate 9.54 9.953 9.999 (Gb/s) Max packet size 200 1800 19000supported (12 IPG) Max packet size 1541 14000 135000 supported (70 IPG)

[0067] The following is a bandwidth performance calculation exampleassuming a constant flow of maximum Ethernet packet length (1518 bytes)with a minimum average IPG of 10.5. This average IPG takes into accountthe RS IPG removal/insertion and frequency compensation. With anavailable data bandwidth of 9.95328 Gbs, the maximum continuous streampacket length is calculated as follows:

(L+IPG _(min))·9.95328·(1−50 ppm)=(L+GFP _(OH))·10G·(1+100 ppm)Δv_(max)=10G·(1+100 ppm)−9.95328·(1−50 ppm)$L = \frac{{9.95278 \cdot {IPG}_{\min}} - {10.001 \cdot {GFP}_{OH}}}{\Delta \quad v_{\max}}$

[0068] The maximum packet length that can be supported is:

[0069] L=allowed packet length=1545 byte

[0070] In the above calculation, the (−50 ppm) and (+100 ppm) values arebased on assumed clock drift values for outgoing and incoming WDMclocks.

[0071] The maximum packet length specified by the IEEE 802.3ae standardis 1518+8 bytes. Therefore, the system and method described herein isable to support a worst-case Ethernet payload without flow control.However, flow control may be required for jumbo frames. Flow control maybe implemented by monitoring the last memory load (i.e., the one thatgenerates the output constant bit stream) and, as soon as a threshold iscrossed, the EFP framing block generating a pause Ethernet packet (e.g.,as defined in IEEE 802.3ae) in order to ask the client interface toreduce the bandwidth load. This method generally avoids the drop ofpacket in case of bandwidth overload.

[0072]FIG. 7 shows a system block diagram of computer system 84 that maybe used as a router or host or used to execute software of an embodimentof the invention. The computer system 84 includes memory 88 which can beutilized to store and retrieve software programs incorporating computercode that implements aspects of the invention, data for use with theinvention, and the like. Exemplary computer readable storage mediainclude CD-ROM, floppy disk, tape, flash memory, system memory, and harddrive. Additionally, a data signal embodied in a carrier wave (e.g., ina network including the Internet) may be the computer readable storagemedium. Computer system 84 further includes subsystems such as a centralprocessor 86, fixed storage 90 (e.g., hard drive), removable storage 92(e.g., CD-ROM drive), and one or more network interfaces 94. Othercomputer systems suitable for use with the invention may includeadditional or fewer subsystems. For example, computer system 84 mayinclude more than one processor 86 (i.e., a multi-processor system) or acache memory.

[0073] The system bus architecture of computer system 84 is representedby arrows 96 in FIG. 7. However, these arrows are only illustrative ofone possible interconnection scheme serving to link the subsystems. Forexample, a local bus may be utilized to connect the central processor 86to the system memory 88. Computer system 84 shown in FIG. 7 is only oneexample of a computer system suitable for use with the invention. Othercomputer architectures having different configurations of subsystems mayalso be utilized. Communication between computers within the network ismade possible with the use of communication protocols, which govern howcomputers exchange information over a network.

[0074] As can be observed from the foregoing, EFP has a low fixedoverhead per packet. EFP makes it possible to carry a full 10 Gb/sEthernet signal in the SONET OC-192C or the OTN OTU2 byte containers.Furthermore, EFP makes it unnecessary to apply any rate control to theclient signal.

[0075] Although the present invention has been described in accordancewith the embodiments shown, one of ordinary skill in the art willreadily recognize that there could be variations made to the embodimentswithout departing from the scope of the present invention. Accordingly,it is intended that all matter contained in the above description andshown in the accompanying drawings shall be interpreted as illustrativeand not in a limiting sense.

What is claimed is:
 1. A method of processing Ethernet signals fortransport in an optical network system, the method comprisingencapsulating Ethernet frames into EFP frames comprising a lengthheader, a converged data link header, and a data area, and mapping saidEFP frames into byte synchronous paths, wherein the converged data linkheader replaces an Ethernet preamble of the Ethernet packet.
 2. Themethod of claim 1 wherein the converged data link header is configuredto provide support for network management
 3. The method of claim 1wherein the converged data link header is configured to supportmultiplexing.
 4. The method of claim 1 wherein the converged data linkheader is configured to support defect handling.
 5. The method of claim1 wherein the byte synchronous path is SONET.
 6. The method of claim 1wherein the byte synchronous path is FEC payload.
 7. The method of claim1 wherein the byte synchronous path is OTU.
 8. The method of claim 1wherein encapsulating comprises replacing a Start-of-Frame Delimiterbyte with a header CRC byte.
 9. The method of claim 1 wherein the lengthheader comprises a length field and a length CRC field.
 10. The method 1wherein the EFP frame is configured to provide single bit errorcorrection.
 11. The method of claim 1 wherein the EFP frame isconfigured to provide multi-bit error detection.
 12. The method of claim1 wherein encapsulating comprises inserting EFP idle frames as fillerframes.
 13. The method of claim 1 further comprising removinginter-packet gaps.
 14. The method of claim 1 further comprisingtransparent mapping of Ethernet stream based on CDL.
 15. The method ofclaim 1 wherein mapping comprises building a constant bit stream. 16.The method of claim 15 further comprising mapping the EFP frame into aforward error correction frame.
 17. The method of claim 15 wherein theconstant bit stream runs at approximately 9.953 Gb/s.
 18. The method ofclaim 1 further comprising sending said Ethernet frames to a PCS codingblock.
 19. The method of claim 1 wherein said EFP frames are mapped intoan OC-192 signal.
 20. The method of claim 19 wherein said packets aremapped without rate control.
 21. The method of claim 19 wherein saidpackets are mapped utilizing rate control.
 22. The method of claim 1wherein said packets are mapped into an OTU2 frame.
 23. The method ofclaim 22 wherein said packets are mapped without rate control.
 24. Themethod of claim 22 wherein said packets are mapped utilizing ratecontrol.
 25. The method of claim 1 wherein said converged data linkheader comprises application specific information.
 26. The method ofclaim 25 wherein the application specific field supports multi-protocollabel switched routing.
 27. The method of claim 1 wherein said convergeddata link header includes a message channel.
 28. The method of claim 1wherein said converged data link header replaced the Ethernet preambleprior to encapsulation of the Ethernet frame.
 29. The method of claim 1further comprising providing an automatic protection switchingsubchannel within said converged data link header.
 30. A method forframing byte aligned variable length packets for transport in an opticalnetwork system, the method comprising replacing a preamble of the packetwith a header comprising an operations, administration, and maintenancefield, a message channel, an application specific field, and a headererror detection field.
 31. The method of claim 30 further comprisingreplacing a Start-of-Frame Delimiter byte with a header CRC byte. 32.The method of claim 30 further comprising mapping the packets into aSONET path.
 33. The method of claim 30 further comprising mapping thepackets into an OTN OTU2 path.
 34. The method of claim 30 furthercomprising mapping the packets into forward error correction frames. 35.The method of claim 30 wherein at least one field of the header isconfigured to support statistical multiplexing.
 36. The method of claim30 wherein the header includes the same number of bytes than thepreamble it replaced.
 37. The method of claim 30 wherein the headerincludes a fewer number of bytes than the preamble it replaced.
 38. Themethod of claim 30 wherein the header further comprises a defectindication field.
 39. A computer program product for processing Ethernetsignals for transport in an optical network system, the productcomprising: code that encapsulates Ethernet frames into EFP framescomprising a length header, a converged data link header, and a dataarea, the converged data link header replacing an Ethernet preamble ofthe Ethernet packet; code that maps said EFP frames into bytesynchronous paths; and a computer-readable storage medium for storingthe codes.